Blanket rename rustc-macro to proc-macro

Auto merge of #3170 - alexcrichton:ignore-rustc-macro, r=alexcrichton

Ignore rustc-macro tests for now

We need to ignore them to land rust-lang/rust#36945 and after that we'll shortly
re-enable them.

Ignore rustc-macro tests for now

We need to ignore them to land rust-lang/rust#36945 and after that we'll shortly
re-enable them.

Auto merge of #3162 - alexcrichton:ugh-mspdbsrv, r=brson

Leak mspdbsrv.exe processes on Windows

Instead of having our job object tear them down, instead leak them intentionally
if everything succeeded.

Closes #3161

Auto merge of #3146 - alexcrichton:install-same-workspace, r=brson

Use workspaces during `cargo install`

Prevent lock files from oscillating.

Closes #3133

Auto merge of #3137 - alexcrichton:bump-curl, r=brson

Update curl to track more error info

This hopefully will help out with https://github.com/rust-lang/cargo/issues/2464#issuecomment-250583778 by including https://github.com/alexcrichton/curl-rust/commit/07323ab5e868babb7a5437e8d2604761b913dab3 which should give us more information from libcurl

Auto merge of #3145 - alexcrichton:rustdoc-cross-test, r=brson

Test requested --target from source of truth

We skip doc tests for any cross compiles (as they don't work) but to detect a
cross compile we checked `--target` but forgot to check other locations like
`CARGO_BUILD_TARGET` or `[build.target]`. This alters the check to ensure that
it verifies from the source of truth whether a cross compilation happened or
not.

Closes #3143

Auto merge of #3136 - alexcrichton:warn-bad-override, r=brson

Warn about path overrides that won't work

Cargo has a long-standing [bug] in path overrides where they will cause spurious
rebuilds of crates in the crate graph. This can be very difficult to diagnose
and be incredibly frustrating as well. Unfortunately, though, it's behavior that
fundamentally can't be fixed in Cargo.

The crux of the problem happens when a `path` replacement changes something
about the list of dependencies of the crate that it's replacing. This alteration
to the list of dependencies *cannot be tracked by Cargo* as the lock file was
previously emitted. In the best case this ends up causing random recompiles. In
the worst case it cause infinite registry updates that always result in
recompiles.

A solution to this intention, changing the dependency graph of an overridden
dependency, was [implemented] with the `[replace]` feature in Cargo awhile back.
With that in mind, this commit implements a *warning* whenever a bad dependency
replacement is detected. The message here is pretty wordy, but it's intended to
convey that you should switch to using `[replace]` for a more robust
impelmentation, and it can also give security to anyone using `path` overrides
that if they get past this warning everything should work as intended.

[bug]: https://github.com/rust-lang/cargo/issues/2041
[implemented]: http://doc.crates.io/specifying-dependencies.html#overriding-dependencies

Closes #2041

Auto merge of #3144 - alexcrichton:less-update-registry, r=brson

Avoid updating registry when adding existing deps

Cargo previously erroneously updated the registry whenever a new dependency was
added on a crate which already exists in the DAG. This commit fixes this
behavior by ensuring that if the new dependency matches a previously locked
version it uses that instead.

This commit involved a bit of refactoring around this logic to be a bit more
clear how the locking and "falling back to the registry" is happening.

Closes #2895

Auto merge of #3157 - japaric:target-rustflags, r=alexcrichton

add support for per-target rustflags in .cargo/config

you can now specify rustflags on a per-target basis in .cargo/config:

``` toml
[target.x86_64-unknown-linux-gnu]
rustflags = ["x86", "specific", "flags"]

[target.arm-unknown-linux-gnueabi]
rustflags = ["arm", "specific", "flags"]
```

If both build.rustflags and target.*.rustflags are specified, the
target.* ones will be used.

As before RUSTFLAGS overrides either set.

closes #3153

r? @alexcrichton I've only added a smoke test and a precedence test. Let me know if I should add more tests!

add documentation about target.$triple.rustflags

Auto merge of #3163 - brson:docdir, r=alexcrichton

Update rust-installer

Update rust-installer

Leak mspdbsrv.exe processes on Windows

Instead of having our job object tear them down, instead leak them intentionally
if everything succeeded.

Closes #3161

add support for per-target rustflags in .cargo/config

you can now specify rustflags on a per-target basis in .cargo/config:

``` toml
[target.x86_64-unknown-linux-gnu]
rustflags = ["x86", "specific", "flags"]

[target.arm-unknown-linux-gnueabi]
rustflags = ["arm", "specific", "flags"]
```

If both build.rustflags and target.*.rustflags are specified, the
target.* ones will be used.

As before RUSTFLAGS overrides either set.

closes #3153

Auto merge of #3139 - jhbabon:improve-replace-parsing-error-msg, r=alexcrichton

Show an error messager for invalid semver spec for packages in the [replace] section.

The `[replace]` section in the `Cargo.toml` file doesn't allow invalid semver specsfor packages, so something like this:

```toml
[dependencies]
foo = "*"

[replace]
"foo:*" = { git = 'https://example.com' }
```

It's not valid. In this case we will display an error message like this:

```
error: failed to parse manifest at `Cargo.toml`

Caused by:
  replacements must specify a valid semver version to replace, but `foo:*` does not

Caused by:
  Parse error
```

closes #3129

Use chain_error in TomlManifest.replace when checking valid semver.

Don't throw away previous error messages, they might be useful
for the user.

Auto merge of #3150 - matklad:deprecate-read-manifest, r=alexcrichton

Document that read_manifest command is deprecated

I believe we intended to deprecate read_manifest command. I am not sure what a deprecation process for Cargo commands should be, but I guess it should involve mentioning somewhere that the command is deprecated :)

Auto merge of #3147 - carols10cents:versions-in-readme, r=alexcrichton

Add information about Cargo releases going with Rust releases

Closes #3101.

This just adds a table of rust release numbers to cargo release numbers, and some text that clarifies that they happen together.

I put the table behind a details tag, which Chrome renders really nicely with a little toggle triangle... Firefox will do the toggling *functionality* but doesn't have much of an indication that you can click on the text, but I think they're working on it. Servo has a little triangle but nothing happens when you click on it ;)

Document that read_manifest command is deprecated

Add information about Cargo releases going with Rust releases

Use workspaces during `cargo install`

Prevent lock files from oscillating.

Closes #3133

Test requested --target from source of truth

We skip doc tests for any cross compiles (as they don't work) but to detect a
cross compile we checked `--target` but forgot to check other locations like
`CARGO_BUILD_TARGET` or `[build.target]`. This alters the check to ensure that
it verifies from the source of truth whether a cross compilation happened or
not.

Closes #3143

Avoid updating registry when adding existing deps

Cargo previously erroneously updated the registry whenever a new dependency was
added on a crate which already exists in the DAG. This commit fixes this
behavior by ensuring that if the new dependency matches a previously locked
version it uses that instead.

This commit involved a bit of refactoring around this logic to be a bit more
clear how the locking and "falling back to the registry" is happening.

Closes #2895
Closes #2931

Auto merge of #3142 - alexcrichton:siphash, r=alexcrichton

Allow deprecated use of SipHasher

This type is being deprecated in rust-lang/rust#36815, so allow use of the
deprecated type for now. We can fix this later once new APIs have landed.

Allow deprecated use of SipHasher

This type is being deprecated in rust-lang/rust#36815, so allow use of the
deprecated type for now. We can fix this later once new APIs have landed.

Show an error messager for invalid semver spec for packages in the [replace] section.

The [replace] section in the Cargo.toml file doesn't allow invalid semver specs
for packages, so something like this:

    [dependencies]
    foo = "*"

    [replace]
    "foo:*" = { git = 'https://example.com' }

It's not valid. In this case we will display an error message like this:

    error: failed to parse manifest at `Cargo.toml`

    Caused by:
      replacements must specify a valid semver version to replace, but `foo:*` does not

Update curl to track more error info

Warn about path overrides that won't work

Cargo has a long-standing [bug] in path overrides where they will cause spurious
rebuilds of crates in the crate graph. This can be very difficult to diagnose
and be incredibly frustrating as well. Unfortunately, though, it's behavior that
fundamentally can't be fixed in Cargo.

The crux of the problem happens when a `path` replacement changes something
about the list of dependencies of the crate that it's replacing. This alteration
to the list of dependencies *cannot be tracked by Cargo* as the lock file was
previously emitted. In the best case this ends up causing random recompiles. In
the worst case it cause infinite registry updates that always result in
recompiles.

A solution to this intention, changing the dependency graph of an overridden
dependency, was [implemented] with the `[replace]` feature in Cargo awhile back.
With that in mind, this commit implements a *warning* whenever a bad dependency
replacement is detected. The message here is pretty wordy, but it's intended to
convey that you should switch to using `[replace]` for a more robust
impelmentation, and it can also give security to anyone using `path` overrides
that if they get past this warning everything should work as intended.

[bug]: https://github.com/rust-lang/cargo/issues/2041
[implemented]: http://doc.crates.io/specifying-dependencies.html#overriding-dependencies

Closes #2041

Auto merge of #3135 - alexcrichton:bump, r=alexcrichton

Bump to 0.14.0

Bump to 0.14.0

Auto merge of #3134 - whitequark:patch-1, r=steveklabnik

doc: build-script: use cfg(unix), not a hardcoded x86_64 triple

This used to not be possible, but it is now, so let's promote best practices.

doc: build-script: use cfg(unix), not a hardcoded x86_64 triple

This used to not be possible, but it is now, so let's promote best practices.

Auto merge of #3127 - kraai:patch, r=alexcrichton

Add newlines to SYNOPSIS sections

Add newlines to SYNOPSIS sections

Auto merge of #3057 - rjgoldsborough:add-policies, r=steveklabnik

adding policies page to the docs

Fixes #3056

Auto merge of #3125 - mbrubeck:dev-deps, r=alexcrichton

Build transitive dev-dependencies when needed

When running `cargo test -p foo` where `foo` is a crate in the current workspace, build and link `foo`'s dev-dependencies. Fixes #860.

Merge pull request #3032 from brson/rust-installer

Update rust-installer

Build transitive dev-dependencies when needed

When running `cargo test -p foo` where `foo` is a crate in the current
workspace, build and link `foo`'s dev-dependencies. Fixes #860.

Auto merge of #3123 - wimh:platform_versions, r=alexcrichton

Don't download dependencies from other platforms

Having a Cargo.toml which looks like this:

            [package]
            name = "a"
            version = "0.0.1"
            authors = []

            [target.'cfg(unix)'.dependencies]
            foo = "0.1.0"

            [target.'cfg(windows)'.dependencies]
            foo = "0.2.0"

This would still download foo version 0.2.0 on unix. I think there is no need to do that, but please correct me if I'm wrong.

This was triggered by [this](http://stackoverflow.com/questions/39709542/why-does-the-last-platform-specific-dependency-take-precedence-in-cargo) stackoverflow question, but that situation is more complicated, as the version is the same, just the features are different. This PR will not solve that bug. If you want me to include that too, I would have to debug a bit more first....

Auto merge of #3089 - carols10cents:crates-io-registry-url, r=alexcrichton

Make crates-io registry URL optional in config; ignore all changes to source.crates-io

Hi! When I was working on the instructions for source replacement [in this crates.io PR](https://github.com/rust-lang/crates.io/pull/440), I found that when I'm replacing `source.crates-io`, [I still have to specify some value for `registry`](https://github.com/rust-lang/crates.io/pull/440/files#diff-04c6e90faac2675aa89e2176d2eec7d8R177), or else I get this:

```
error: no source URL specified for `source.crates-io`, need either `registry` or `local-registry` defined
```

This seems weird and annoying to me: cargo definitely knows the registry URL for crates-io, and I'm trying to replace it anyway.

So the first commit in this PR makes it optional, so that you don't have to specify a registry url for crates-io: it uses `SourceId::crates_io`, like it would if we didn't have any source configs at all.

~~The second commit in this PR might go too far, and/or might break existing uses of cargo, I'm not sure. In my opinion, `source.crates-io` should only be able to be replaced and never changed directly-- crates-io should always be crates-io, and I should be able to assume that in any project. So the second commit ignores all modifications to `source.crates-io`'s `registry`, `local-registry`, and `directory`, and warns that they're being ignored.~~

~~I tried to search github to see if anyone was using these keys with `source.crates-io`, but since github's search ignores `.` (ARE YOU LISTENING GITHUB? I WOULD LIKE TO SEARCH WITH PUNCTUATION PLEASE), there's a lot of false positives to wade through. I didn't see anything in the first few pages though.~~

I'm happy to make whatever modifications to this!

Do not download dependencies from other platforms

add test cfg/ignore_version_from_other_platform

if different platforms have a dependency to a different
version of a crate, only the correct dependency should
be downloaded and used

Auto merge of #3110 - jsgf:topic-license-metadata, r=alexcrichton

cargo: add license and license_file to cargo metadata output

Proposed fix for #3108

Auto merge of #3122 - shepmaster:patch-1, r=steveklabnik

Add missing quotation mark

Add missing quotation mark

Auto merge of #3091 - matklad:move-exec-streamed, r=alexcrichton

Move stream_output to ProcessBuilder

Make `stream_output` method more reusable (I intend to use it in #3000).

Unrelated question: what is that `ExecEngine` thing? Looks like it does nothing at the moment and can be removed.

Auto merge of #3118 - cbiffle:master, r=alexcrichton

Fall back to fs::copy when hard_link fails.

Some filesystems don't allow hard links.  Since Cargo's use of hard
links is an optimization, and not necessary for correctness, it can fall
back to a file copy when hard linking is not available.

This is one possible solution to #3098.

Caveat: this will try to copy if the hard link fails *for any reason*.
It's not clear that there's a more surgical way of handling this; Unix
tends to indicate the condition as "permission denied," not with a
granular "links not supported by filesystem" error.

Auto merge of #3121 - alexcrichton:bump-openssl, r=alexcrichton

Update OpenSSL again to 1.0.2j

Update OpenSSL again to 1.0.2j

Should not have to specify crates-io registry URL to replace-with

Since cargo knows crates-io's registry URL and, anyway, you're trying to
say that you don't want to use crates-io.

cargo: add license and license_file to cargo metadata output

Auto merge of #3104 - jturner314:fix-publish-man-page, r=alexcrichton

Remove duplicate option in cargo-publish man page

The `--host` option was listed twice; this commit removes one of the duplicates.

Fall back to fs::copy when hard_link fails.

Some filesystems don't allow hard links.  Since Cargo's use of hard
links is an optimization, and not necessary for correctness, it can fall
back to a file copy when hard linking is not available.

This is one possible solution to #3098.

Caveat: this will try to copy if the hard link fails *for any reason*.
It's not clear that there's a more surgical way of handling this; Unix
tends to indicate the condition as "permission denied," not with a
granular "links not supported by filesystem" error.

Auto merge of #3117 - alexcrichton:bump-openssl, r=alexcrichton

Update OpenSSL used by Cargo

Update OpenSSL used by Cargo

Remove duplicate option in cargo-publish man page

The `--host` option was listed twice; this commit removes one of the
duplicates.

Move stream_output to ProcessBuilder

Auto merge of #3092 - jhbabon:fix/dont-panic-on-workspaces, r=alexcrichton

FIX: Don't try to generate Gargo.lock on empty workspaces.

There was a `panic!` when the command `cargo update` was executed in a workspace like this:

    mkdir ws
    cd ws
    echo '[workspace]' > Cargo.toml
    cargo new p1
    cargo new p2
    cargo update

The problem is that cargo tries to generate the `Cargo.lock` file even if there aren't any members on the workspace.

This fix checks the existence of members in the workspace before trying to do anything so at least we report an error instead of throwing a `panic!`.

Issue related https://github.com/rust-lang/cargo/issues/3080

FIX: Don't try to generate Gargo.lock on empty workspaces.

There was a panic! when the command `cargo update` was
executed in a workspace like this:

    mkdir ws
    cd ws
    echo '[workspace]' > Cargo.toml
    cargo new p1
    cargo new p2
    cargo update

The problem is that cargo tries to generate the Cargo.lock file
even if there aren't any members on the workspace.

This fix checks the existence of members in the workspace before trying
to do anything so at least we report an error instead of throwing a
panic!

Auto merge of #3087 - carols10cents:test-instructions-in-readme, r=alexcrichton

Document recommended way for running tests

Fixes #3084.

Document recommended way for running tests

Fixes #3084.

Auto merge of #3083 - jhbabon:fix-warning-in-feature-tests, r=alexcrichton

FIX: Properly close dep_feature_in_cmd_line test.

It was including the test `all_features_flag_enables_all_features` inside its function body and it was causing this warning when executing `cargo test`:

```
   Compiling cargo v0.13.0 (file:///home/jhbabon/Code/cargo)
tests/features.rs:965:1: 1006:2 warning: function is never used: `all_features_flag_enables_all_features`, #[warn(dead_code)] on by default
tests/features.rs:965 fn all_features_flag_enables_all_features() {
                      ^
tests/features.rs:964:1: 964:8 warning: unused attribute, #[warn(unused_attributes)] on by default
tests/features.rs:964 #[test]
                      ^~~~~~~
     Running target/debug/features-e37991fdf417989c
```

Properly close dep_feature_in_cmd_line test.

It was including the test all_features_flag_enables_all_features
inside its function body.

Auto merge of #3078 - jhbabon:fix/parse-home-config-once, r=alexcrichton

Fix: Don't parse the home directory more than once

This PR tries to resolve this issue https://github.com/rust-lang/cargo/issues/3070. The problem is that the `walk_tree` method in the `src/util/config.rs` module was parsing more than once the contents of the config file in the home directory (the file `~/.cargo/config`). The biggest problem with this is with options that can accept multiple values, like `build.rustflags`. If you parse the file twice, the same option can end with duplicated values (e.g: `rustflags=["-Z", "foo", "-Z", "foo"]`).

I made the fix following the comments in the issue. In the fix I keep track of all the parsed config files in a `HashSet` so I can know if a file has been parsed already. ~~I'm also using `std::fs::canonicalize`, as suggested in the issue, to prevent parsing files behind symbolic links more than once.~~

**UPDATE:** I removed the call to `fs::canonicalize` as suggested in the comments. Now the fix is way simpler, which means less code and less possibilities to add a new bug.

Remove fs::canonicalize in walk_tree fix.

* Remove ConfiFile struct, it is not needed without the fs::canonicalize
  call.
* Don't check if the file is in the stash when walking the tree,
  without "canonicalization" it is not necessary.

Add ConfigFile struct to handle config file paths.

Don't parse the config in home if it was parsed already.

This is the first version of the fix. It needs clean up.

Add a test that reproduces the error of parsing home config twice.

Auto merge of #3064 - dtolnay:rustc-macro, r=alexcrichton

Macros 1.1

Tested with https://github.com/serde-rs/serde/pull/530. This should be able to merge independently of https://github.com/rust-lang/rust/pull/35957.

r? @alexcrichton

Bump rustcversion to pick up rustc-macro support

Auto merge of #3073 - pnkfelix:clarify-lib.name-in-Cargo.toml, r=alexcrichton

doc fix: clarify lib.name property

doc fix: clarify lib.name property

`extern crate` uses `lib.name`; default is post '-' => '_' substitution.

Auto merge of #3071 - japaric:moar-cargo, r=alexcrichton

prepare for cargo for mips and powerpc

with these changes I can cross compile Cargo for these targets:

- mips-unknown-linux-gnu
- mipsel-unknown-linux-gnu
- powerpc-unknown-linux-gnu
- powerpc64-unknown-linux-gnu
- powerpc64el-unknown-linux-gnu

using these commands:

```
$ ./.travis.install.deps.sh
$ ./configure --local-rust-root=$(pwd)/rustc --enable-nightly --target=$TARGET
$ make
```

in Ubuntu 16.04 using the standard cross toolchains

r? @alexcrichton
cross compiling Cargo for the mips targets requires rust-lang/libc#378

docfix: `extern crate` uses `lib.name`; default is post '-' => '_' substitution

Auto merge of #3072 - pietroalbini:fix-faq, r=steveklabnik

Remove reference of Rust 1.11.0 release date in the FAQ

In the `--frozen` section of the FAQ, there is a reference to the Rust 1.11.0 release date (probably because it was added in June), which is now in the past. In this pull request I removed that reference, since it's not useful anymore.

I also reflowed the text to 80 chars, to be consistent with the rest of the document :)

Remove reference of Rust 1.11.0 release date in the FAQ

This commit also reflows the text after removing the reference.

Empty commit to trigger Travis build of rustc-macro

prepare for cargo for mips and powerpc

with these changes I can cross compile Cargo for these targets:

- mips-unknown-linux-gnu
- mipsel-unknown-linux-gnu
- powerpc-unknown-linux-gnu
- powerpc64-unknown-linux-gnu
- powerpc64el-unknown-linux-gnu

using these commands:

```
$ ./.travis.install.deps.sh
$ ./configure --local-rust-root=$(pwd)/rustc --enable-nightly --target=$TARGET
$ make
```

in Ubuntu 16.04 using the standard cross toolchains

Auto merge of #3068 - binarybirchtree:generalize-error-message, r=alexcrichton

Generalize error message used by both `cargo package` and `cargo publish`.

Resolves issue #3061.

This pull request updates the wording of the error message in question to be applicable to both `cargo package` and `cargo publish`, and adds a test case for the example in the issue description.

Generalize error message used by both `cargo package` and `cargo publish`.

Explicitly bind Some(false)

Auto merge of #3060 - rillian:package_path_deps, r=alexcrichton

Reject path-based dependencies in `cargo package`

`cargo publish` will complain if a package manifest contains a path, rather than registry+version-based dependency. Make `cargo package` do the same so that issue is caught sooner in developer workflow.

Auto merge of #3063 - Wilfred:patch-1, r=alexcrichton

Clarify wording: this restriction is not just libraries

I found the previous wording a little confusing (see [discussion on users.rust-lang.org](https://users.rust-lang.org/t/uploading-binary-packages-not-libraries-to-crates-io/7072)).

Since the section heading specifically refers to libraries, I was puzzled that crates.io rejected my binary package with wildcard dependencies (plus a Cargo.lock file). I think this wording is clearer, let me know what you think.

Ideally we'd also say the reasoning behind rejecting wildcard dependencies for binary crates, but I don't know what the reasoning is.

Test a crate that is both a plugin and a proc macro

Test for rustc-macro

Auto merge of #3065 - mbrock:master, r=alexcrichton

doc: mention feature toggling in "Specifying deps"

Basically copies info that was already on another page.

doc: mention feature toggling in "Specifying deps"

Linewrap the error message from check_metadata.

This lets test result expected output pass the long-line style check.

Macros 1.1

Clarify wording: this restriction is not just libraries

Verify `cargo package` rejects path dependencies.

Port of the equivalent test from the `cargo publish` command.

Check for path dependencies.

Port registry::verify_dependencies to the `cargo package`
command to perform the local portion of that check. It
looks like the package operation doesn't generally make
reference to the registry, so skip variant-origin checks
until publish time.

Auto merge of #3038 - esclear:master, r=alexcrichton

Add --all-features flag to cargo

As (more or less) requested in #1173 I added a `--all-features` flag to cargo that builds all available features.

I hope I documented it in all the right places.

If there's something weird or wrong, please give me a heads up.

Add --all-features flag to cargo

Merge pull request #1 from steveklabnik/rjgoldsborough-add-policies

tweak policies

tweak policies

adding policies to Makefile.in

adding policies page to the docs

Merge pull request #3055 from rust-lang/revert-3054-simplify

Revert "Replace for loop with iterators"

Revert "Replace for loop with iterators"